本系列文之前談的偏重在後端的技術問題，但是請千萬不要忘了，開發資訊系統才是我們的最終目的。所以今天我想來談談開發資訊系統時，如何才能「如期、如質、如預算」的完成系統的開發，以及可能會面臨的困難。

開發企業資訊系統(ERP)時，最難掌握的部份並非程式撰寫，而是規格的確立。而能否順利結案，也是依交付的程式，功能是否和規格確認書一致為判斷的依據。話雖如此，但是仍然有部份的軟體開發專案，會面臨專案的尾款很難收回的冏境。原因通常是在驗收時，部份功能與客戶所預期不同，除了部份是程式的問題外，很大的部份是所謂的「灰色地帶」，客戶常會說

「你們是專業的軟體公司，這麼基本的功能，本來就應該有」 或是

「這是我們這個行業本該就有的基本功能，為什麼你們沒有考慮到」

「就是因為我們不懂電腦，你們比較專業，所以才找你們，怎麼可能連這麼簡單、基本的功能，都要我們一一的描述」

這類問題很難完全避免，特別是專案比重愈高的case，越容易有類似的爭議。這個問題的根源，就是本文的主題，「行業別專業知識（Domain Know how）」。

俗話說「三百六十行，行行出狀元」，現在的行業別早就遠遠的超越以往，三千六百行都不止，分工更加的細緻。而每個行業都有其特定的管理重點。單就以買賣業的進銷存管理為例，鞋子和衣服類的產品，就要比一般的產品多了「尺寸」「顏色」要記錄管理。而鋼材業則是以重量（噸或公斤）或長度（公尺或碼）來管理庫存及應收付帳款。有些產品甚至有雙單位的需求（如一箱2支）。一旦基本的單位不同，各種單據就會有不同的欄位需求，相關的分析報表就會有所不同。

除了計量單位外，還有不同的國家或地區的稅制不同，在台灣，就有二聯式、三聯式等等多樣的發票聯式。而發票稅率大部份都是5%，少數特殊的品項是免稅或零稅。但是在中國大陸則是不同的產品可能會有不同稅率的問題。甚至連螢幕上的字型大小、報表列印的字體等，也會是個麻煩。如果在加上一些慣有的軟體操作習慣，如按「Enter」跳到下一個欄位等，有太多的「眉角」要注意。雖然說起來都是一些小問題，但很多的小問題匯整在一起，就可能會是大災難。以上所述都還是比較簡單、普遍的例子。實際上不同行業別的差異會因為不同的業別有更多的細節待處理。

解決之道：

標準的核心版本

最好先有一個標準的核心版本(或是先前開發的類似專案)。和使用者討論時，務必以該版本的操作介面為準，就可以避免許多操作介面的爭議。

利用 Wizard，產生雛型程式

利用 Wizard 的優勢，先產生雛型程式（ProtoType），用來和客戶確認規格。

所謂的ProtoType是指利用Wizard產生出第一個版本的可操作程式，類似早期的程式產生器。通常是由專案經理(PM)或系統分析師(SA) 在了解客戶的需求後，將規格輸入到 Wizard 程式中，然後產生程式碼。在這個階段中並不須要使用研發單位的任何資源。而且產生的程式碼經過客戶的確認後，會交給程式設計師繼續維護，增添功能後，就是日後交付的正式版本，並不僅僅只是Demo展示用。而更完整的 Wizard 程式會更進一步的產生相關的規格文檔。如此一來就可避免先前一般的專案開發，都是用Word（或Excel）文檔和客戶確認規格，但是客戶並無法實際操作來確認是否正確，光憑文檔上的描述，一定會有溝通的盲點。當然，規格文檔還是必要的，雛型程式和規格文檔互相配合，就可以避免很多的負面效應。

開發與測試並行

絕大多數的疾病，如果能「即早發現，即早治療」通常都有很大的機會可以治好。

一般專案的驗收期都在專案的結案日期前，也就是專案的後期，如果一切順利那就還好，一旦在驗收期才發現大問題，那就會有大麻煩了。正確的作法，應該是事先跟客戶溝通好，在開發期間就應該備好一台測試主機，經內部測試無誤的程式，應定期更新到測試主機上，並請客戶配合測試，如果有問題，可以直接填寫issue到專案管理模組中的issue Tracking系統。客戶可以隨時掌握目前的進度，不會因為資訊不足，導致在專案後期才發現重大的問題。當然，驗收期還是必須的，不過此時的驗收重點是在測試數字的正確性，而非操作介面的問題。

測試案例的編寫

如何才算驗收合格？如何才能確認雙方對規格的認知沒有誤差及錯漏？
要確定上述的問題，測試案例（Test Case）應該是一個很好的工具。測試案例最好由客戶依某一週或月的實際工作內容編寫，務必要包含全部專案的絕大部分功能。範本的格式則通常可以由獨立軟體開發商提供。但是通常十之八九客戶都沒有辦法獨立完成，

所以這個工作通常是以

1.客戶負責提供完整的測試資料內容及應有的重要報表數字（含報表格式）
2.PM或SA依前述的內容編寫測試案例內容
3.雙方在初期頻繁的討論測試案例的內容，試圖發現是否有漏失重要的流程及功能。

的過程來共同完成。

測試案例的最大優點，在於可以透過收集來的資料，確認對客戶的需求是否完全理解，因為在串接客戶資料流的過程中，如果有滯礙難行或不合理的地方，通常在這個過程會很快被挖掘出來。不過跟據筆者個人的經驗，大部份的客戶都會延遲一段時間才給，甚至給的殘缺不全，因為提供資料可能會涉及不同的部門及人員，而且提供資料者本身就有很多業務待辦，反正就是會有一堆聽起來很有道理的藉口。

無論如何，請相信我，一份完整的測試案例會讓專案在進行中，避免很多溝通的缺漏及誤解，無論再怎麼困難，都必須搞定它。這當然很大程度是在考驗 PM 的功力以及平常是否和客戶的關係打好，PM 和客戶方的MIS窗口是否保持良好的關係及溝通，往往會在關鍵時刻發揮重大的功能，千萬不要小看這些細節。

Domain Know how 是否熟悉了解，對整個系統的成功與否佔極重要的角色。基本上它就是要完全的分析理解客戶的所有規章及業務流程，然後將其轉為資訊化作業。在這個過程中，甚至會幫客戶盤點出很多的不合理（或矛盾）的規定或制度，或是沒有規範到的例外情況，這也算是另類的企業診斷。

開發企業的資訊系統，當然不可能只是單純的技術問題，更重要的是 PM 溝通協調能力及對 Domain Know how的掌握。但是技術能力也不能偏廢，資訊技術是基礎，技術能力必須厚積才能薄發，必須要不斷的累積技術能量。這也是很多技術人員的升遷之路，是在累積許多的專案經驗後，會升遷為系統分析師的原因。

最後的幾個單元，會再聊聊開發的標準四化，希望能對您有點幫助，感謝您的收看，明天再會。